FastSemaphore Overview

A FastSemaphore provides synchronization functionality to threads within a process who need a low-latency, high-speed signaling mechanism that requires little memory. By allowing threads the ability to enter a busy-wait state, the latency involved in waking a thread when a thread is signaled will not occur.

The FastSemaphore allows threads in a multiprocessor environment to remain busy until signaled. The advantage is a quicker return to the run state. Since there are no objects associated with FastSemaphores, there are a number of restrictions that developers should be aware of before using a FastSemaphore, including the following:

• All threads sharing a FastSemaphore must be in the same process.
• All threads should have access to the same RTFAST_SEMAPHORE structure variable.
• The RTFAST_SEMAPHORE structure variable must be allocated for the duration of all busy-waits.
• The controlling process must not be killed while a wait is active.
  • All waiters threads must exit before the process exits or the process may hang.
• The developer must carefully manage thread priorities - threads are not protected by priority inversion protocols.
• Threads using a FastSemaphore should not execute on processor zero, as the busy-wait state could interfer with execution of the RTX subsystem.
• Threads executing on a shared mode processor should not use a fastsemaphor eas the busy-wait state could interfer with execution of the Windows subsystem.
• FastSemaphore rely on a busy wait so you should disable starvation monitoring since a FastSemaphore can trigger an unintentional Starvation exception.
• Threads sharing a FastSemaphore should execute on different processors to ensure that
  • A busy-wait thread does not interfere with the FastSemaphore release thread.
  • A high priority busy-wait thread does not interfere with a lower priority FastSemaphore release thread.